[レポート] Hyperspaceでデータレイクのインデックスをカバーする – Subsurface LIVE Summer 2021

Subsurface LIVE Summer 2021

#イベントレポート

#データレイク

しんや

2021.08.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

米国時間2021年07月21日〜22日の計2日間、オンラインで開催された「Subsurface LIVE Summer 2021」では、主催となるDremio社のサービスやクラウドデータレイクに関する各種サービスやプロダクトのセッションが展開されていました。

Subsurface LIVE Summer 2021

当エントリでは、その中から「Covering Indexes in the Data Lake with Hyperspace」(Hyperspaceでデータレイクのインデックスをカバーする)というセッションについてレポートします。

セッション概要

セッション概要は以下の通り。

Covering Indexes in the Data Lake with Hyperspace - Subsurface

＜セッションタイトル＞
Covering Indexes in the Data Lake with Hyperspace
(Hyperspaceでデータレイクのインデックスをカバーする)

＜登壇者＞
Andrei Ionescu - Sr Software Engineer, Adobe Experience Platform's Data Lake team @ Adobe

＜発表内容＞
At Adobe, we use the Iceberg table format inside the Adobe Experience Platform Data Lake. Although Iceberg offers the capability for file skipping, when the data is properly laid out and used, in many cases this is not enough, and the queries executed over the data take a long time to complete. Similar to an RDBMS use case where high latency on queries can be alleviated with additional indexing at the cost of some extra storage, in data lakes the same pattern can be used. Hyperspace is an early phase indexing subsystem for Apache Spark that introduces the ability for users to build indexes on data, and together with Iceberg it can bring major improvements in query response time – up to 25 times faster in some cases. Hyperspace accommodates our two major data flow use cases – stale datasets and fast-changing datasets – and assures consistency when used.

(アドビでは、Adobe Experience Platform Data Lakeの中でIcebergテーブル形式を使用しています。Icebergにはファイルをスキップする機能がありますが、データが適切にレイアウトされて使用されている場合、多くのケースではそれだけでは不十分で、データに対して実行されるクエリには長い時間がかかります。RDBMSの使用例では、クエリの待ち時間が長い場合、ストレージを追加してインデックスを追加することで緩和することができますが、データレイクでも同じようなパターンを使用することができます。Hyperspaceは、Apache Sparkの初期段階のインデックス作成サブシステムで、ユーザーがデータにインデックスを作成する機能を備えています。Hyperspaceは、2つの主要なデータフローのユースケース（古いデータセットと急速に変化するデータセット）に対応し、使用時の一貫性を保証します。)

セッションレポート

ここからはセッションレポートとなります。それぞれのトピックに関して要点をまとめる形で紹介。

アジェンダ

Adobe Experience Platform Data Lakeの概要
なぜIcebergなのか
インデックス、カバリングインデックス
Hyperspaceを使うメリット
ベンチマーク
基本的なAPI
どのように機能するのか
ハイブリッドスキャンとの整合性
デモ
リソース

Adobe Experience Platformデータレイクの概要

アドビエクスペリエンスプラットフォームのデータレイクの概要

10TB/日の処理
平均 1000 cols/ds
平均 10 TB/ds
平均 5K の変更/秒

なぜIcebergなのか

データの信頼性
- スキーマの強制力の欠如により、型の不整合や破損が発生する可能性がある
- Sparkジョブの失敗により、結果の一部がダウンストリームに読み込まれることがある
- リーダとライタが同時進行すると、コンフリクトが発生し、データが失われることがある
読み取りの信頼性
- 大規模なテーブルの場合、ディレクトリやファイルのリストアップが遅くなる（O(n)）。
- データの再記述により、読み取りに一貫性がなくなる。
- 粗い粒度の分割計画では、非効率なデータスキャンが発生する
スケーラビリティ
- 独立したメタデータ・サービスに依存すると、Single Point of Failure（単一障害点）が発生する危険性がある
- スケールプランニングのためには、メタデータの削除、圧縮、書き換えが必要

インデックス、カバーリングインデックス

種類
- クラスター化
- クラスター化されていないインデックス（例：カバリングインデックス
カバーリングインデックスとは？
- クエリを解決するために必要なすべての情報を含むインデックスは「カバリングインデックス」と呼ばれ、クエリを完全にカバーしている
なぜ必要なのか？
- Icebergのデータスキップは、すべてのユースケースでパフォーマンスを発揮するわけではない
- 除外しなければならない列が多過ぎる
- インデックスを事前に処理しておくことで、処理コストをストレージコストに変換することができる

Hyperspaceとは

クエリやワークロードを高速化するためのインデックスを自動的に構築、維持、活用することができるシンプルなシステム

Hyperspace

Hyperspaceを使うメリット

シンプルなAPI
多言語対応(Scala、Python、.NET)
複数ユーザによる同時実行モード
アプリケーションに影響を与えない変更
既存のデータセットのデータレイアウトを保持
処理コストとストレージコストの交換
バージョニングとアイソレーション
一貫性の確保
- インクリメンタル・リフレッシュ
- ハイブリッドスキャン
Apache Sparkの補完を目的としている
シングルテナントとマルチテナントの両方に対応

ベンチマーク

TPC公式ベンチマーク
- 平均して2倍の改善
- 1.1倍から10倍までの範囲
当社テスト
- 大規模なデータセットで20倍の性能向上(15億行、13TBのデータ)

Basic APIs

参考リソース
- Hyperspace
- index for package com.microsoft.hyperspace - hyperspace-core_2.12 0.4.0 javadoc
サンプル例
- Import Hyperspace(Hyperspaceのインポート)
- instantiate Hyperspace(Hyperspaceのインスタンス化)
- Create Index(インデックス作成)
- Search Query(検索クエリ)
- Explain command(コマンドの説明)
- Enable Hyperspace for query time(問い合わせ時にHyperspaceを有効にする)
- Execute Query(クエリの実行)
- Disable Hyperspace for query time(問い合わせ時にHyperspaceを無効にする)
- Show all indexes(全てのインデックスを表示)
- Other APIs(その他API)
どうやって動作する？
- (実行時に)クエリが実行されると、Hyperspaceはインデックスを使用するようにSparkプランを書き換える
参考：
- Hyperspace, an indexing subsystem for Apache Spark™, is now open source - Microsoft Open Source Blog

ハイブリッドスキャンによる一貫性の確保

データとインデックスを同期させるには？
- Q: 本当に同期する必要があるのか？新しいデータが入るたびにインデックスを修正する必要があるのか？
- R: そんなことはない
ハイブリッドスキャン
- 構築されたインデックスを使用して、前回の更新からの変更をインデックスに追加
- 単純なケースでは、新しいファイルをファイルインデックスに追加
- 複雑なケースでは、インデックスと新しいデータの間に結合を作成
- 削除の場合は、削除されたレコードを除外するフィルタを追加
メリット
- データとインデックスの両方に非同期で書き込みが可能
- インデックスを最大限に活用できる